KVS STREAMS

TL;DR — Постановка задачи: выжать максимум из эрланга в плане
производительности записи абстрактных сообщений (например из gen_server) на
диск. Область применения: базостроение и хранение первичных транзакционных
цепочек. Условия использования: много маленьких сообщений, которые нужно
склеивать в буфера или накапливать, а потом быстро сбрасывать на диск.

Цифры (пропускная способность) относительно MBA 2013:

— просто raw recieve: 1M msgs/s msg_size=128
— просто raw prim_file write: 700 MB/s, msg_size=8MB/s код тут
— накапливание сообщений: 231941 msgs/s msg_size=128
— сброс на диск с вариативным буфером: 200 MB/s в 2 потоках msg_size=4K

Пока есть вариация только по размеру буфера, я хочу добавить вариацию по
размеру сообщения, т.е. предварительно еще схлопывать сообщения на втором
уровне, чтобы минимизировать длинну списка бинарей, которая идет в качестве
iolist на диск. И тогда уже будут какие-то вменяемые данные.

Пока ситуация такая, что выжать максимум можно 200MB/s в двух потоках, в
четырех потоках пропускная способность на поток падает, но вцелом получаются те
же 200MB/s.

Пример сессии:

1> observer:start().
ok

2> writer:test(1).
whereis writer: <0.386.0>
<0.386.0>
Written writer1: rate 185 MB/s messages 6149 in 0 sec
Written writer1: rate 182 MB/s messages 45368 in 2 sec

3> writer:test(2).
whereis writer: <0.499.0>
<0.499.0>
Written writer2: rate 171 MB/s messages 6149 in 0 sec
Written writer1: rate 158 MB/s messages 44676 in 2 sec
Written writer2: rate 156 MB/s messages 42105 in 2 sec
Written writer1: rate 144 MB/s messages 38833 in 2 sec
Written writer2: rate 147 MB/s messages 38278 in 2 sec
Written writer1: rate 147 MB/s messages 35481 in 2 sec

ecirca надо хачить так как там пословное управление буфером, поэтому я вернулся
к накапливаю бинарей в очередях потоков эрланга (так все делают), но по
прежнему подумываю о каком-то непрерывном массиве, который мы знаем как быстро
сбрасывать на диск. Проблема как быстро его заполнить сообщениями на 4 ядрах.

Так же я в тест включил HMAC подпись сообщений, можете ее тоже посмотреть, кому
интересно когда весь стрим подписан цепочным хешом (частичный случай
древовидного хеширования, как во всяких блокчейнах).

Если кому интересно, можно почитать код тут: https://github.com/5HT/streams
Там его как всегда мало. Написано без OTP, на самопальном gen_server (как
бонус). Т.е. использовалось только:

— spawn/receive/send
— gen_server:call как клиент (streams — OTP compatible)
— register/unregister/whereis

Т.е. все приведено к виду который можно легко портировать на другие языки.